Those functions are not yet in LAPACK 3.11 (they are scheduled for a future
LAPACK release). Since the Debian package for OpenBLAS relies on the latest
stable LAPACK release, we have to (temporarily) remove support for them.
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
[changes brought forward from 0.2.15-1+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Fri, 11 Mar 2016 23:39:32 +0000]
* Disable arm-gcc-flags.patch which was enforcing gcc flags that are wrong
for raspbian.
Those functions are not yet in LAPACK 3.11 (they are scheduled for a future
LAPACK release). Since the Debian package for OpenBLAS relies on the latest
stable LAPACK release, we have to (temporarily) remove support for them.
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
* New upstream version 0.3.24+ds
* d/copyright: reflect upstream changes
* mips64-generic.patch: drop patch, applied upstream
* revert-lapack-gedmd.patch: new patch for compiling against LAPACK 3.11
* Build on loong64 architecture
* d/rules: pass the number of requested parallel jobs to the build system.
Previously the build system would always use as many parallel jobs as there
are logical CPU cores.
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
* Install CMake files under /usr/lib/$(MULTIARCH)/cmake/openblas$(FLAVOR)/
Thanks to Juan Jose Garcia Ripoll for reporting (Closes: #1000332)
* no-embedded-lapack.patch: fix logic for detecting build with 64-bit
indexing. In particular, this fixes the riscv64 packages whose embedded
LAPACK routines were unusable with 32-bit indexing.
Thanks to Дмитрий Ермилов (Closes: #1022950)
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
Mo Zhou [Sat, 21 May 2022 20:25:13 +0000 (21:25 +0100)]
openblas (0.3.20+ds-2) unstable; urgency=medium
* Remove deprecated xCOMBSSQ lapack routines. (Closes: #1011386)
* Remove bin:libjulia-openblas64, which is no longer needed.
Exporting libopenblas64_.so with SYMBOLSUFFIX=64_ in Julia private
library as an external dependency introduces complication in Julia
package compiling process. We currently do not have proposal to
put libopenblas64_.so (with symbol suffix) in the public library,
because that will eventually lead to NINE variants to build for amd64:
(1) LP64 (32-bit indexing), three threading models, default;
(2) ILP64 (64-bit indexing), three threading models, no symbol suffix;
(3) ILP64 (64-bit indexing), three threading models, symbols suffix 64_.
Currently we only provide the (1) and (2) combinations, because BLAS
libraries without symbol mangling can still be alternated to e.g. MKL.
Mo Zhou [Mon, 21 Feb 2022 10:14:52 +0000 (10:14 +0000)]
Fix symbol mangling for libjulia-openblas64
Forwarded: not-needed
Last-Update: 2020-08-01
when building libjulia-openblas64, we place the lapack shared objects under
lapack64-netlib/ directory. But if exports/gensymbol cannot detect the
existence of the lapack-netlib directory, it will skip the lapack symbol which
results in incomplete symbol mangling (SYMBOLSUFFIX=64_) through objcopy.
Last-Update: 2020-08-01
Gbp-Pq: Name gensymbols-fix-detect-netlib.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
Mo Zhou [Fri, 14 Jan 2022 14:21:00 +0000 (14:21 +0000)]
Fix symbol mangling for libjulia-openblas64
Forwarded: not-needed
Last-Update: 2020-08-01
when building libjulia-openblas64, we place the lapack shared objects under
lapack64-netlib/ directory. But if exports/gensymbol cannot detect the
existence of the lapack-netlib directory, it will skip the lapack symbol which
results in incomplete symbol mangling (SYMBOLSUFFIX=64_) through objcopy.
Last-Update: 2020-08-01
Gbp-Pq: Name gensymbols-fix-detect-netlib.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
Mo Zhou [Mon, 20 Dec 2021 12:27:29 +0000 (12:27 +0000)]
Fix symbol mangling for libjulia-openblas64
Forwarded: not-needed
Last-Update: 2020-08-01
when building libjulia-openblas64, we place the lapack shared objects under
lapack64-netlib/ directory. But if exports/gensymbol cannot detect the
existence of the lapack-netlib directory, it will skip the lapack symbol which
results in incomplete symbol mangling (SYMBOLSUFFIX=64_) through objcopy.
Last-Update: 2020-08-01
Gbp-Pq: Name gensymbols-fix-detect-netlib.patch
The libopenblas binaries do not include libmatgen code, so don't mark them as
exported and don't test for their presence (in linktest).
Last-Update: 2016-03-24
Gbp-Pq: Name matgen-symbols-not-included.patch
* It is done so that duplicate code with libopenblas.so.0 is kept as low as
possible. Only the symbols from the external BLAS/LAPACK API are incorporated
in the shared libraries. The rest is obtained by dynamic linking against
libopenblas.so.0. This also gives access to some extra OpenBLAS symbols, in
order to differentiate it at runtime from other BLAS implementations (see
#960728).
The -rpath,'$ORIGIN' is there to ensure that the OpenBLAS flavour used is
the one selected in the lib{blas,lapack}.so.3 alternative, and not the one
selected in the libopenblas.so.0 alternative.
* See also override_dh_shlibdeps in debian/rules
* Also order the files when calling `ar' or $(CC), to make
the build reproducible (see #824639)
* Also link the shared blas and lapack against gomp (see #945791)
Last-Update: 2020-07-31
Gbp-Pq: Name shared-blas-lapack.patch
Adapt build system for the absence of lapack-netlib/ and relapack directories.
Forwarded: not-needed
Last-Update: 2017-07-27
Instead use the binary provided by package liblapack-pic, stripping from it the
symbols that are overridden by OpenBLAS.
Last-Update: 2017-07-27
Gbp-Pq: Name no-embedded-lapack.patch
Under kFreeBSD, give a SONAME to the shared library and install it. Also link
it against libm.
Simply use the same code as Linux for all these operations.
Last-Update: 2014-08-05
Gbp-Pq: Name kfreebsd.patch
Use flags suitable for armhf port when TARGET=ARMV6
Forwarded: not-needed
Last-Update: 2015-04-29
See debian/rules for an explanation of why we can't use TARGET=ARMV7 on armhf.
Also, if we don't explicitly set the -march and -mfpu flags, the resulting
static libraries crash with SIGILL (reason not yet elucidated).
Last-Update: 2015-04-29
Gbp-Pq: Name arm-gcc-flags.patch
projects / openblas.git / log